-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "Library Retention Times" column to the Document Grid #2613
base: master
Are you sure you want to change the base?
Conversation
…in the Fold Change grid seem to disappear immediately. Also, simplify class "SkylineObjectList" by removing generic argument "TKey" so the class's only generic argument is "TItem".
The "LibraryRetentionTimes" column will contain a comma-separated list of all of the retention times that were found in any of the spectral libraries. There are sub-properties "MinLibraryRetentionTime", "MaxLibraryRetentionTime", "MeanLibraryRetentionTime" Issue 138: Add report value for spectral library retention time
…k/20230609_LibraryRetentionTimes # Conflicts: # pwiz_tools/Skyline/Model/Databinding/Collections/ResultList.cs
Hmmm... Our other library values are at the Precursors level. It feels like rolling everything up to the peptide level is losing information about when precursors were actually identified. And staying at the precursor level allows you to promote the "best" spectrum time for that precursor, maybe. |
Good points. Sometimes people would want to know the whole range of retention times without regard to charge state or isotope label type. Someone at ASMS wanted to use these times when exporting numbers that would eventually be used in a method. It seems to be surprisingly difficult to add this column to "Precursor" right now. I was able to use the existing method "GetUnalignedRetentionTimes" to get the times across all files and all charge states and label types. But, if I wanted to get the times across all files and for a particular charge state and label type, that would be a lot of calls to "Library.TryGetLibraryRetentionTimes". |
It may be worth keeping in mind that we will want to make this even more complicated to allow spectral libraries with properties that match the new precursor filters. e.g. being able to match spectra in a .blib to either the Orbitrap filter or the LIT filter, but not necessarily both. I can see how we would not be well prepared for light v. heavy, since this distinction doesn't impact fragmentation, and we go out of our way to use either for transition selection for the other. I would expect it to be easier to differentiate by charge state, since that does impact fragmentation greatly. But, in the case of the Document Grid, I think you would want to pay attention to light v. heavy and strictly match spectra to the exact precursor used for a row. |
…k/20230609_LibraryRetentionTimes
…k/20230609_LibraryRetentionTimes
This change adds a "Library Retention Times" to the Peptide level in the Document Grid.
The "Library Retention Times" column contains a comma-separated list of all of the retention times for the peptide from any library.
It has sub-properties "MinLibraryRetentionTime", "MaxLibraryRetentionTime" and "MeanLibraryRetentionTime".
This fixes Issue 138: Add report value for spectral library retention time
Does this seem like a reasonable way to deal with the fact that peptides usually have several retention times in the libraries?